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METHOD AND SYSTEM FOR CONTROLLING A REAL-TIME 
COMMUNICATIONS SERVICE 
Field of the invention 

[0001] The present invention relates to real-time communications services in com- 
munication systems. 
Background of the Invention 

[0002] Particularly in the third-generation (3G) mobile communications systems, a 
public land mobile network (PLMN) infrastructure may be logically divided into core 
network (CN) 9,10,11,12 and access network (AN) infrastructures 5,6,7,8, as illus- 
trated in Figure 1 . The access network AN may be called a base station subsystem 
(BSS) 8 for GSM and a radio network subsystem (RNS) or a radio access network 
(RAN) 5,6,7 for UMTS. In the technical specifications of the third-generation part- 
nership project (3 GPP), the core network CN is logically divided into a circuit- 
switched (CS) domain 9, a packet-switched (PS) domain 10,11 and an IP multimedia 
subsystem (IMS) 12. The CS domain refers to the set of all the CN entities offering a 
"CS type of connection" for user traffic as well as to all the entities supporting the re- 
lated signaling. A "CS type of connection" is a connection for which dedicated net- 
work resources are allocated during connection establishment and released during 
connection release. A "PS type of connection" transports user information using 
packets so that each packet can be routed independently. An example of the PS do- 
main is GPRS (General Packet Radio Service), and typical entities may include a serv- 
ing GPRS support node (SGSN) and a gateway GPRS support node (GGSN). The IP 
multimedia subsystem comprises all CN elements for the provision of multimedia ser- 
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vices. The IP multimedia subsystem IMS utilizes the PS domain to transport multi- 
media signaling and bearer traffic. 

[0003] Push-to-talk over Cellular (PoC) is an overlay speech service in a mobile cel- 
lular network where a connection between two or more parties is established (typi- 
cally) for a long period but the actual radio channels in the air interface are activated 
only when somebody is talking. This corresponds to the usage of the traditional radio- 
telephones where the used radio frequency is agreed between the parties (e.g. mili- 
tary/police radios, LA radios, walkie-talkie type of radios) and whenever somebody 
wants to talk s/he presses the tangent, which activates the radio transmission on the 
selected channel. The traditional radiotelephone services are simplex so that only one 
party (the one who is pressing the tangent) can talk at a time. More specifically, dur- 
ing voice communication with a "push-to-talk, release-to-listen" feature, a call is 
based on the use of a pressel (PTT, push-to-talk switch): by pressing PTT the user in- 
dicates his/her desire to speak, and the user equipment sends a service request to the 
network. Alternatively, a voice activity detector (VAD) or any suitable means can be 
used instead of the manual switch. The network either rejects the request or allocates 
the requested resources on the basis of predetermined criteria, such as the availability 
of resources, priority of the requesting user, etc. At the same time, a connection is 
also established to a receiving user, or users in the case of group communication. Af- 
ter the voice connection has been established, the requesting user can talk and the 
other users can listen. When the user releases PTT or, in the case of traffic inactivity, 
the event is detected in the network, and the resources may be released and/or the talk 
item may be granted to another user. Thus, the resources are reserved only for the 
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actual speech transaction or speech item, instead of reserving the resources for a 
"call". 

[0004] Modern cellular networks, especially in the GSM/GPRS/UMTS network evo- 
lution, include new packet-mode (e.g. IP) voice and data services. Push-to-talk over 
Cellular (PoC) service can be provided as a packet-based user-level or application- 
level service so that the underlying communications system only provides the basic 
connections (i.e. IP connections) between group communications applications in the 
user terminals and a group communication service. The PoC communication service 
can be provided by a communication server system while the client applications reside 
in the user equipment or terminals. Examples of this approach are disclosed in co- 
pending U.S. patent applications 09/835,867; 09/903,871; and 10/160,272; and in 
WO 02/085051. 

[0005] With the PoC service, first the connection(s) between the parties is typically 
established via the packet-switched (PS) mobile network, for example a packet- 
switched (PS) core network. In practice, this means that a Voice over IP (VoIP) 
(group or one-to-one) call is set up between the parties. However, as described above, 
the difference to a conventional phone call is that the radio channel of the subscribers 
is activated only when somebody needs to talk and released when nobody is talking. 
[0006] The PoC service is a practical solution for the cases when the parties need to 
talk relatively rarely but whenever somebody needs to talk, the connection has to be 
activated fast and easily (e.g. when giving instructions to the members of a hunting 
team in the forest or to a crane driver at a construction site). Because in this type of 
applications, the calls are typically long but the voice activity is low, it is essential to 
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release the bearer (e.g. radio channels) when nobody is talking in order to save the 
radio and network capacity and terminal batteries. On the other hand, the bearer re- 
sources should be available with as small a delay as possible when voice activity again 
starts. 

Disclosure of the Invention 

[0007] An object of the invention is to decrease the delay associated with voice 
transmission in real-time media communication. 

[0008] The object is achieved by the invention defined in the attached independent 
claims. Preferred embodiments of the invention are defined in the sub-claims. 
[0009] An aspect of the invention is a method of controlling a real-time media ses- 
sion, comprising 

sending first signaling from first user equipment via a serving access 
network of the first user equipment to a first media communication server in response 
to user's action during an established real-time media session, 

sending second signaling from the first media communication server 
towards the first user equipment, 

sending third signaling from the first media communication server 
towards second user equipment, 

sending immediately after the first signaling and/or the second signaling 
and/or the third signaling dummy media traffic from the first media communication 
server towards the first user equipment, in order to trigger a dedicated-channel setup 
for the first user equipment and/or the second user equipment in the serving access 
network of the first user equipment prior to beginning an actual user media stream 
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from the first user equipment. 

[OOIO] An aspect of the invention is a method of controlling a real-time media ses- 
sion, comprising 

establishing a real-time media session between first user equipment and 
second user equipment via a serving access network of the first user equipment, via at 
least a first media communication server, and via a serving access network of the 
second user equipment, 

sending, by the media communication server or a support node in a 
packet-switched core network during inactive periods of the real-time media session, 
dummy media towards at least one of the first and second user equipment in order to 
reset an inactivity timer of a common channel state in the serving access network of 
the respective user equipment and to thereby prevent the respective user equipment 
from going to an idle state. 

[0011] An aspect of the invention is a media communication server for providing 
real-time media sessions between sets of user equipment located in one or more access 
networks, wherein 

the media communication server is configured to receive first signaling 
sent by first user equipment via a serving access network of the first user equipment in 
response to user's action during an real-time media session established between the 
first user equipment and second user equipment, 

the media communication server is configured to send second signaling 
towards the first user equipment upon receiving said first signaling, 

the media communication server is configured to send third signaling 
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towards the second user equipment upon receiving said first signaling, 

the media communication server is configured to send immediately after 
the first, second and/or third signaling dummy media traffic towards the first and/or 
second user equipment in order to trigger a dedicated-channel setup for the first and/or 
second user equipment in the respective serving access network prior to beginning an 
actual user media stream from the first user equipment. 

[0012] In an embodiment of the invention, a media communication server is config- 
ured to send dummy media traffic to first and/or second user equipment only if the 
session inactivity prior to first signaling exceeds a certain threshold, in order to limit 
the amount of unnecessary dummy data sent. 

[0013] An aspect of the invention is a support node for a packet-switched core net- 
work, wherein 

the support node is configured to establish a real-time media connection 
between user equipment located in a radio access network, and a media 
communication server, 

the support node is configured to send during inactive periods of the real- 
time media connection dummy media towards the user equipment in order to reset an 
inactivity timer of a common channel state in the radio access network and to thereby 
prevent the respective user equipment from going to an idle state. 
[0014] An aspect of the invention is user equipment for a communication system, 
wherein 

the user equipment is configured to establish a real-time media session 
via an access network and a media communication server, 
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the user equipment is configured to send a first signaling via the access 
network to the media communication server in response to user's action during the 
established real-time media session, and 

the user equipment is configured to send immediately after the first 
signaling dummy media traffic to the media communication server in order to trigger 
a dedicated-channel setup for the user equipment in the access network of the first 
user equipment prior to beginning an actual user media stream. 

[0015] In an embodiment of the invention, the user equipment is configured to send 
dummy media traffic to the media communication server only if the session inactivity 
time prior to sending the first signaling exceeds a certain threshold, in order to limit 
the amount of unnecessary dummy data sent. 

[0016] The invention is based on sending dummy data (e.g. a dummy message) in 
order to maintain a dedicated channel during the inactive periods of a real-time media 
session or to trigger an early dedicated-channel setup in an access network. The 
invention prevents sets of user equipment that are logged on to a real-time media (e.g. 
PoC) session from going to a radio resource idle state and, therefore, it prevents 
potential long extra delays during real-time media (e.g. PoC) service usage. The 
invention further allows sending and receiving user equipment to set up dedicated 
channels (DCH) already during the start-to-talk procedure of the transmitting user 
equipment, which in turn potentially reduces end-to-end delays during the 
conversation. 
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Brief Description of the Drawings 

[0017] The above and other objects, features and advantages of the present invention 
will become more apparent in light of the following detailed description in conjunc- 
tion with the drawings, in which 

[0018] Figure 1 illustrates a communications system having a radio access network 
RAN, CS and PS core networks, and a PoC server, 

[0019] Figure 2 is a block diagram illustrating functional blocks of a PoC server ac- 
cording to an example embodiment of the invention, 

[0020] Figure 3 is a block diagram illustrating basic blocks of user equipment accord- 
ing to an example embodiment of the invention, 

[0021] Figure 4 illustrates the various states of user equipment UE in WCDMA, 
[0022] Figure 5 is a signaling diagram illustrating an example of a signaling flow for 
maintaining an active state of user equipment, 

[0023] Figure 6 is a flow diagram illustrating an example of operation of a PoC server 
or a support node according to an embodiment of the invention, 

[0024] Figure 7 is a signaling diagram illustrating an example of a signaling flow for 
setting up a media communication, 

[0025] Figure 8 is a flow diagram illustrating an example of the operation of UE in 
accordance with the principles of the present invention, 

[0026] Figure 9 is a flow diagram illustrating an example of the operation of a PoC 
server in accordance with the principles of the present invention, and 
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[0027] Figure 10 is a signaling diagram illustrating an example of a signaling flow for 
a communication event where a previous speaker stops speaking and a previous re- 
cipient starts speaking. 

Detailed description 

[0028] The present invention is applicable to communications systems enabling real- 
time media sessions between end-users. The real-time data may include real-time au- 
dio (e.g. speech), real-time video, or any other real-time data, or a combination 
thereof, i.e. real-time multimedia. 

[0029] The present invention is especially applicable to communications systems al- 
lowing packet-mode real-time data communication, such as IP packet communication 
between end users. Thus, the real-time data communication may be carried out be- 
tween end-user terminals over the Internet, for example. 

[0030] The present invention offers a significant improvement for packet-mode 
speech communications. The voice over Internet Protocol (VoIP) enables speech 
communication over an IP connection. In some embodiments of the invention, the IP 
voice communication method employed is the Voice over IP (VoIP), but the invention 
is not limited to this particular method. 

[0031] As an example of a system environment, to which the principles of the present 
invention may be applied, will be described with reference to Figure 1. In Figure 1, a 
Push-to-talk Over Cellular (PoC) server system is provided on top of the Packet- 
Switched (PS) core network 10, 11, 12 in order to provide a packet-mode (e.g. IP) 
voice, data and/or multimedia communication services to the User Equipment (UE) 1, 
2, 3, 4. UE accessing PS CN, and the PS core network itself, utilizes the services pro- 
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vided by the Radio network subsystem (RNS) or Radio access network (RAN) 5, 6, 7, 
8 to provide packet-mode communication between UE and the PS CN subsystem. 
The multiple access method employed in the air interface in RAN may be Time Divi- 
sion Multiple Access (TDMA), Frequency Division Multiple Access (FDMA), Code 
Division Multiple Access (CDMA), or a combination thereof. In the third- and 
higher-generation mobile communications systems, the access method is primarily 
based on CDMA. Further, because the traffic channels may have a wide bandwidth, 
corresponding to user data rates, for example up to 2 Mbits/s, such access may also to 
be referred as Wideband CDMA (WCDMA). 

[0032] As regards the PoC type services, examples of this concept are disclosed in 
co-pending U.S. patent applications 09/835,867; 09/903,871; 10/160,272; and in WO 
02/085051. Conceptually, a packet-based media communications system is provided 
on top of the mobile network in order to provide media communications services to 
the user equipment UE through the communications system. The media communica- 
tions system may be embodied as a server system, and it is generally referred to as a 
media communications server herein. There may be a plurality of media communica- 
tions servers 14, 15. As illustrated in the example configuration of Figure 2, the me- 
dia communications server may comprise control-plane functions CPF and user-plane 
functions UPF providing packet-mode server applications that communicate with the 
communication client application(s) in the user equipment UE over the IP connections 
provided by the communications system. This communication includes signaling 
packets and voice or data communication packets. The CPF function is responsible 
for the control-plane management of the group communication. This may include, for 
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example, managing the user activity and creation and deletion of logical user-plane 
connections with an appropriate control protocol, such as Session Initiation Protocol 
(SIP). The user-plane function(s) UPF is responsible for the distribution of the data or 
speech packets to the user terminals according to their group memberships and other 
settings. UPF forwards traffic only between valid connections programmed by CPF. 
Speech communication may be based on the voice over IP (VoIP) protocol, and/or 
Real-time Transport Protocol (RTP). It should be appreciated that the user-plane op- 
eration relating to the data or speech traffic is not relevant to the present invention. 
However, the basic operation typically includes that all the data or speech packet traf- 
fic from a sending user is routed to UPF which then delivers the packet traffic to the 
receiving user(s). The PoC server may include further entities, such as a register and a 
subscriber and group management function SGMF. 

[0033] User equipment UE may be a wireless device, such as mobile user equipment, 
or it may be a device connected by a fixed connection, such as a dispatcher station. 
Herein the term user equipment and the corresponding acronym UE is used to refer to 
any device or user equipment allowing the user to access network services. 
[0034] As an exemplary embodiment, the user equipment UE, such as a Mobile Sta- 
tion MS, may have a PoC application on a user layer on top of the standard protocol 
stack used in the specific mobile communications system. An appropriate session 
control protocol, such as Session Initiation Protocol (SIP), may be used for the PoC 
control-plane signaling. The voice communication may be based on IP communica- 
tion (such as voice over IP, VoIP), and RTP (Real-time Transport Protocol, defined in 
RFC 1889) may be employed to handle the voice packet (VoIP) delivery on the user 



plane. The SIP and RTP protocols employ the underlying Transmission Control Pro- 
tocol (TCP), User Datagram Protocol (UDP) and IP protocols that further employ the 
physical layer resources, such as the radio resources. For example, the underlying 
connection in a mobile communications network may be based on a GPRS connec- 
tion. 

[0035] An example of a possible implementation of user equipment is illustrated in a 
simplified block diagram shown in Figure 3. An RF part 304 represents any radio 
frequency function and hardware required by the specific air interface employed. The 
actual implementation of the RF part 304 is not relevant to the present invention. 
Baseband signal processing 309 represents any baseband signal processing required in 
any specific implementation, such as an analog-digital (A/D) conversion of the ana- 
logue speech signal from the microphone 310, vo-encoding, IP packet building, frame 
building, deframing, IP packet debuilding, vo-decoding, a digital-analog (D/A) con- 
version of the received digital speech signal into an analog signal applied to a loud- 
speaker 311. A controller 305 controls the operation of the RF unit 304 and the base- 
band signal-processing unit 309. The controller 305 controls the signaling, both out- 
band (SIP) and embedded, as well as IP packet building and debuilding. The start and 
stop of the speech items are set by the PTT switch 306 which can be replaced by any 
user-operated device, such as a voice activity detector (VAD). Such alternative 
mechanisms for starting and ending a speech item instead of PTT are obvious to a per- 
son skilled in the art. A user interface may include a display 307 and a keyboard 308. 
It should be appreciated that the blocks illustrated in Figure 3 are functional blocks 
that can be implemented in a variety of different circuit configurations. For example, 



the baseband processing and the controller may be implemented in a single program- 
mable unit (e.g. a CPU or a signal processor) or in a plurality of units. The operation 
according to the present invention is primarily related to the controller part of MS, and 
the basic invention may be implemented as program modifications to the control pro- 
gram of MS, for example. It should also be appreciated that the present invention is 
not intended to be restricted to mobile stations and mobile systems but the terminal 
can be any terminal having a speech communication capability. For example, the user 
terminal may be a terminal (such as a personal computer PC) having Internet access 
and VoIP capability for voice communication over the Internet. 

[0036] In the embodiment of Figure 3, the controller 305 comprises a media commu- 
nication client application 301 (e.g. PoC client). The media communication client 
application 301 (e.g. PoC client) provides the respective communication service. For 
example, in case of PoC group communication, the client application 301 may main- 
tain group information, such as group identification information and group member- 
ship information. The communication client 301 may also provide tools for group 
creation, for attaching to (joining) a group and for detaching from (leaving) the group, 
starting and ending the speech items, etc. 

[0037] In PS core networks based on GPRS or the like, UE a) performs a GPRS at- 
tach procedure, and b) establishes a PDP context (i.e. a bearer) used for SIP signaling. 
This PDP context will remain active throughout the period UE is connected to PS CN, 
i.e. from the initial registration and at least until deregistration. As a result, the PDP 
context provides UE with information that enables UE to construct an IP address. 
During the establishment of a session, UE establishes data stream(s) for media related 
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to the session. Such data stream(s) may result in the activation of an additional PDP 
context(s), i.e. bearer(s). Such an additional PDP context(s) is established as a secon- 
dary PDP context associated with the PDP context used for signaling. In other core 
network environments, bearers of other type may be used. It should be appreciated 
that the basic invention is basically independent of the type of core network. 
[0038] It should be appreciated that there are many applications of the Internet world 
that require the creation and management of a session, where a session is considered 
an exchange of data between a group of participants. The implementation of these 
applications is complicated by the practices of the participants: users may move be- 
tween endpoints, they may be addressable by multiple names, and they may commu- 
nicate in several different media - sometimes simultaneously. Therefore, the present 
invention is not restricted to PoC services but can be applied to the media flow man- 
agement of such other applications as well. 

[0039] Numerous protocols have been authored that carry various forms of real-time 
multimedia session data, such as voice, video, or text messages. The Session Initia- 
tion Protocol (SIP, RFC 3261) is a general-purpose tool for creating, modifying, and 
terminating sessions that works independently of underlying transport protocols and 
without dependency on the type of session that is being established. SIP can be used 
with other IETF protocols to build up a complete multimedia architecture. Typically, 
these architectures will include protocols such as the Real-time Transport Protocol 
(RTP) (RFC 1889) for transporting real-time data and providing QoS feedback, the 
Real-Time streaming protocol (RTSP) (RFC 2326) for controlling the delivery of 
streaming media, the Media Gateway Control Protocol (MEGACO) (RFC 3015) for 
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controlling gateways to the Public Switched Telephone Network (PSTN), and the Ses- 
sion Description Protocol (SDP) (RFC 2327) for describing multimedia sessions. 
[0040] It should be appreciated that VoIP and PoC are only examples of real-time 
media which the present invention can be applied to. It should also be appreciated 
that the type of media session set up on the application level or the protocols used for 
controlling the media session on that level are not relevant to the basic invention. The 
present invention primarily relates to controlling the access bearers on the access- 
network level, e.g. radio access bearers in RAN. 

[0041] In the following, a few example embodiments of the present invention will be 
described using 3 GPP RAN (WCDMA) as an example of the access network. 
[0042] In the 3 GPP radio access environment, the user equipment may assume vari- 
ous protocol states. Figure 4 summarizes the mapping of the UE states, including the 
states in GSM, to the appropriate 3 GPP and GSM specifications that specify UE be- 
havior. These specifications are incorporated herein by reference. However, only UE 
connected state, CELL DCH, CELL FACH, and CELL_PCH are of interest in the 
following example embodiments of the invention. 

[0043] After power on, UE stays in Idle Mode until it transmits a request to establish 
an RRC (Radio Resource Control) Connection. In Idle Mode the connection of UE is 
closed on all layers of the access stratum. In Idle Mode UE is identified by non- 
access stratum identities, such as an International mobile subscriber identity (IMSI), 
Temporary mobile subscriber identity (TMSI) and Packet TMSI (P-TMSI). In addi- 
tion, RNS has no information of its own on the individual Idle Mode UEs, and it can 
only address all UEs in a cell or all UEs monitoring a paging occasion. 
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[0044] The RRC Connected Mode is entered when the RRC Connection is estab- 
lished. UE is assigned a radio network temporary identity (RNTI) to be used as UE 
identity on common transport channels. The transition to the RRC Connected Mode 
from the Idle Mode can only be initiated by UE by transmitting a request for an RRC 
Connection. The event is triggered either by a paging request from the network or by 
a request from higher layers in UE. 

[0045] When UE receives a message from the network that confirms the RRC con- 
nection establishment, UE enters the CELLFACH or CELLDCH state of RRC 
Connected Mode. The RRC states within RRC Connected Mode reflect the level of 
UE connection and the transport channels that can be used by UE. 
[0046] In the CELL DCH state, a dedicated physical channel is allocated to UE in 
uplink and downlink, UE is known on cell level according to its current active set, and 
dedicated transport channels, downlink and uplink shared transport channels, and a 
combination of these transport channels may be used by UE. 

[0047] The CELL DCH-state is entered from Idle Mode through the setup of an RRC 
connection, or by establishing a dedicated physical channel from the CELL FACH 
state. Transition to CELL FACH state occurs when all dedicated channels have been 
released, which may be via explicit signaling (e.g. PHYSICAL CHANNEL RECON- 
FIGURATION, Radio Bearer Reconfiguration, Radio Bearer Release, Radio Bearer 
Setup, Transport Channel Reconfiguration, etc.), or at the end of the time period for 
which the dedicated channel was allocated. 

[0048] A transition from CELLJDCH- state to CELL FACH state may occur after a 
predetermined period of inactivity. The period is monitored by means of an inactivity 
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timer or timers. The period can be set to any value, typical value being 5 to 10 sec- 
onds. 

[0049] In CELLFACH state, no dedicated physical channel is allocated to UE and 
UE continuously monitors FACH in the downlink. RAN may know the position of 
UE on cell level, i.e. according to the cell where UE last made a cell update. 
[0050] A transition from CELL FACH to CELL DCH state occurs, when a dedi- 
cated physical channel is established via explicit signaling (e.g. PHYSICAL CHAN- 
NEL RECONFIGURATION, RADIO BEARER RECONFIGURATION, RADIO 
BEARER RELEASE, RADIO BEARER SETUP, TRANSPORT CHANNEL RE- 
CONFIGURATION) 

[0051] A transition from CELL-FACH state may occur after a predetermined period 
of inactivity. The period is monitored by means of an inactivity timer or timers. The 
period can be set to any value, a typical value being 5 to 10 seconds. 
[0052] In CELL PCH state, no dedicated physical channel is allocated to UE. UE 
selects one PCH (Paging Channel) with a suitable algorithm, and uses discontinuous 
reception (DRX) for monitoring the selected PCH. Thus, the power consumption in 
UE will be reduced. No uplink activity is possible. The position of UE is known by 
UTRAN on cell level according to the cell where UE last made a cell update in 
CELL FACH state. A transition from CELL_PCH state into Idle mode may occur 
after a predetermined period of inactivity. The period is monitored by means of an 
inactivity timer or timers. The period can be set to any value, a typical value being 
relatively long, for instance 20 to 40 minutes. 
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[0053] Push-to-talk over Cellular (PoC) is a speech service in a mobile network 
where a connection between two or more parties is (typically) established for a long 
period but the actual radio channels in the air interface are activated only when 
somebody is talking. With the PoC service, the connections between the parties are 
typically established via a packet-switched mobile network. In practice this means 
that a Voice over IP (VoIP) (group) call is set up between the parties. However, the 
difference to a conventional phone call is that the radio channel of the subscribers is 
activated only when somebody needs to talk and released when nobody is talking. In 
more general terms, there is a streaming-type real-time media signal having a session 
of long duration but requiring dedicated access resources (e.g. DCH) only 
occasionally with fast set-up times. There is a need for a method and means for 
controlling the activating and releasing of the access bearer so that the fast set-up time 
is achieved. 

[0054] As noted above, UE that does not transmit or receive any data (i.e. is inactive) 
will after some time go to radio resource control (RRC) Idle state. The operator can 
configure the timer controlling the inactivity of UE in RNC, the default inactivity 
threshold being normally in the order of dozens of minutes, for instance 30 minutes. 
The inactivity detection function of RNS (e.g. RNC) may also be based on some other 
criteria, such as traffic volume control, traffic measurement, RLC buffers, timers, etc. 
UE that is in idle state will need more time to set-up a new data connection. This is 
because the set up procedure involves more signaling (e.g. RRC). The time needed to 
go from idle state to active state (CELL PCH) is more than five seconds, and to 
CELL DCH typically more than 10 seconds. 
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[0055] The five-second setup time to go from Idle state to CELL PCH is not an issue 
for end-users using data services such as FTP, web browsing, MMS, etc. This is 
mainly because these services can tolerate some extra delays if they are rare enough. 
However, for a PoC user that is logged on to a PoC session, five extra seconds of 
- start-to-talk time or delay as compared with the other RRC states is definitely too 
much. The start-to-talk delay may be defined as the time after the PTT button is 
pressed until the start-to-speak indication is given to the user (the user can start speak- 
ing). According to performed PoC service usability studies, a start-to-speak delay of 4 
to 5 seconds is still experienced as annoying. A delay of 1 second or less would not 
be noticed at all. A delay less than 3 seconds can be considered of a reasonable qual- 
ity. Thus, there is a need to reduce the communication setup delays. 
[0056] Referring now to Figures 5 and 6, an example of a first aspect of the present 
invention will be described. An inactivity timer Tl is provided in a media communi- 
cation (e.g. PoC) server for an ongoing real-time media (e.g. PoC) session. Each time 
an activity (e.g. PoC data) is detected in the session (step 61 in Figure 6), the inactiv- 
ity timer Tl is reset (step 62). If no activity has been noticed in a session for a prede- 
fined time Tl (step 63), then the server 14 will send dummy traffic (e.g. data or mes- 
sage) to all UEs 2, 3 that belong to this session (step 64). The dummy traffic, when 
received in the radio access network RNS 5, 6, will reset (steps 51, 52 in Figure 5) the 
inactivity or idle timer(s) T2,T3 controlling the transition from CELL_PCH state (in 
more general terms, from a common channel state) to Idle state. As a result, the UEs 
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2, 3 that are logged on to real-time (e.g. PoC) sessions are prevented from going into 
Idle state and can always be kept in active states. There are several advantages in this 
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solution. Firstly, no (parameter) change is needed in the (e.g. WCDMA) radio net- 
works. For example, the idle timer T2, T3 can be configured as default. The amount 
of sent dummy data is small because UE typically goes to Idle state after a relatively 
long period T2, T3 (e.g. 30 minutes) of inactivity. Therefore, the real-time media (e.g. 
PoC) server can send dummy packets at relatively long intervals TKT2, T3, for in- 
stance every 25 minutes, if no activity has been detected in one session. UE that dis- 
connects from a real-time (e.g. PoC) session will not receive dummy packets and, 
therefore, may go to Idle state as normally if it is inactive long enough. Dummy 
packets may also be sent from the server to UEs that are not using the access network 
(e.g. WCDMA radio networks) that do not contain the idle timer (e.g. GPRS-GSM or 
WLAN or LAN). In such cases this method does not improve the performance at all. 
However, it does not decrease the end-to-end service performance either, since these 
dummy packets will not affect end-to-end services. 

[0057] In an embodiment of the invention, the above issue is overcome such that the 
UEs that are in access networks (e.g. WCDMA) notify the server (e.g. by sending 
their dummy packets or any other packet) that they need to receive dummy data in 
order to keep them in active state. As a consequence, the server knows to which UE it 
should send dummy packets. Any system performance degradation in GPRS net- 
works, for instance, is avoided. For example, in Figure 1, if all UEs 1,2,3,4 are logged 
in a PoC session, all except UE1 that is located in the BSS/GSM access network 
would receive dummy data from the PoC server. 

[0058] According to an embodiment of the present invention, a support node in a 
packet-switched core network 10,11 that provides a real-time media connection to 
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user equipment UE is configured to send during inactive periods of the real-time me- 
dia connection dummy media towards the user equipment in order to reset an inactiv- 
ity timer of a common channel state in the radio access network and to thereby pre- 
vent the respective user equipment from going to Idle state. In other words, the func- 
tionality described above regarding the PoC server (Figures 5 and 6) is implemented 
in the support node. When the packet-switched core network is a GPRS (General 
Packet Radio Service) type core network, the support node comprises a serving GPRS 
service node or a gateway GPRS service node. SGSN or GGSN can determine that a 
flow accessing a certain Access Point will benefit from receiving from time to time 
some dummy data in order to wake the UE(s) up. SGSN also knows which radio ac- 
cess technology the UE is using and can, therefore, send dummy data for example to 
WCDMA terminals only but will not send dummy data to UEs located in GSM BSS. 
[0059] Referring now to Figures 7 and 8, examples of a second aspect of the present 
invention will be described. 

[0060] As noted above, the communication setup delays are very critical performance 
indicators of the PoC service and other corresponding real-time media 
communication. DCH (dedicated radio channel) will need to be established for the 
PoC service at least for carrying voice data traffic. DCH establishment delays are 
around 1 second from the active states. The DCH establishment delays can be quite 
annoying during a PoC conversation especially because DCH delays are counted for 
each UE so the total end-to-end delay is up to 2*DCH setup time. 
[0061] It should be appreciated that UE that is in cellPCH state, for instance, will 
not go to cellDCH (i.e. establish DCH) when it has data to send. UE measures the 
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amount of data to be transmitted in the transmission buffer in UE and reports the 
buffer status to the radio network controller RNC in RNS in order to assist in dynamic 
radio bearer control. The measurement parameters can be set by RNC. Measurement 
reports can be triggered using two different mechanisms, periodical and event trig- 
gered. The reporting criteria are specified in the measurement control message and 
may include one or more of Buffer Occupancy, Average of Buffer Occupancy, and 
Variance of Buffer Occupancy. UE performs measurements and transmit measure- 
ment reports according to the measurement control information. For uplink data 
transmission, UE reports the observed traffic volume to the network in order for the 
network to re-evaluate the current allocation of resources. This report contains for 
example the amount of data to be transmitted or the buffer status in UE. The traffic 
volume or the buffer status depends on the activity of higher-layer functions in UE. 
For example, in the PoC service, the operation of a speech codec in UE may be such 
that when a voice activity detector (VAD) indicates silence (and/or the user does not 
press the tangent), the speech codec does not provide any data to the access network 
(e.g. to the RLC buffer) in UE, not even silence indicator frames, which are generated 
during a conventional voice connection supporting discontinuous transmission (DTX). 
[0062] When the UE user wants to say something to the other member(s) in the PoC 
call, s/he presses the tangent in UE. The tangent button activates the speech codec 
regardless of the voice activity and the speech codec starts to generate data into the 
RLC buffer in UE. When UE is in a common channel state (e.g. CELLJFACH), it 
reports the event to RNC, which activates the transition to CELL DCH state. 
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[0063] RNC allocates the required capacity (including DCH), detects a need to 
change the RLC parameters, carries out a radio link setup procedure with a base sta- 
tion BS, and commands UE to CELLDCH state. 

[0064] Similarly, RNC may detect a capacity need in the downlink direction (e.g. 
based on traffic volume measurements, the downlink buffer status) and activate the 
transition to CELL_DCH state. 

[0065] The amount of data sent by UE needs to be large enough (128 bytes by de- 
fault) and, therefore, signaling messages sent during the start-to- talk procedure may 
not be big enough to trigger DCH. These messages may instead be sent over RACH 
and FACH. The amount of data needed to trigger DCH is configurable but again op- 
timal values can not be selected according to one service only in the radio access net- 
work RNS. 

[0066] Thus, according to another aspect of the present invention, a media 
communications server (e.g. the PoC server), and possibly sending UE, is forced to 
send enough data so that the set-up of DCH is triggered during the start-to-talk proce- 
dure. This dummy data is preferably sent immediately after sending the actual signal- 
ing message relating to the initiated start-to-talk procedure. As noted above, signaling 
in the PoC environment comprises Session Initiation Protocol (SIP) messages and 
Real-time Transport Control Protocol (RTCP) messages. Messages typically related 
to the start-to-speak situation include SIP REFER Request, SIP INVITE Request, 
RTCP Floor Request, and RTCP Floor Taken message. 

[0067] Compressed SIP signaling messages are slightly over 200 bytes in size 
whereas RTCP Floor Granted/Taken/Request messages are less than 100 bytes. In an 
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embodiment of the invention, the amount of dummy data sent immediately after send- 
ing the signaling message (e.g. SIP REFER or RTCP FLOOR REQUEST or RTCP 
FLOOR TAKEN) is such that the total amount of data (signaling message + dummy 
data) is large enough to trigger DCH for the sending UE and/or the receiving UE(s). 
As a consequence, the amount of dummy data can be quite small: tens of bytes in case 
of a sent SIP message and around 150 bytes in case of an RTCP message. The aim of 
the invention is thus achieved with the minimum sent overhead data, and the capacity 
of the system is not wasted due to the invention. 

[0068] Figure 7 shows a signaling diagram illustrating an example of starting a real- 
time media transaction, (e.g. a PoC speech), in accordance with an embodiment of the 
present invention. Figure 8 illustrates an example of the operation of UE in accor- 
dance with the principles of the present invention. Figure 9 illustrates an example of 
the operation of a PoC server in accordance with the principles of the present inven- 
tion. 

[0069] Let us assume that the user equipment UE2 is initially in CELL FACH state 
or CELL PCH state. When the user of UE2 wants to say something to the other 
member(s) in the PoC session, s/he presses the pressel PTT 306 in UE. The PoC ap- 
plication 301 in the controller 305 detects that the pressel PTT is pressed (step 81 in 
Figure 8), and generates a SIP REFER message (or SIP INVITE) and transfers it to 
the RLC transmit buffer in UE2 (steps 82 and 83). Further, in accordance with an 
embodiment of the invention, the PoC application (or e.g. the speech codec) also gen- 
erates dummy data which is also transferred to the RLC buffer in UE2 (step 84). The 
amount of the dummy data is such that the total data level in the RLC buffer will ex- 
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ceed the DCH threshold (e.g. 200 bytes). As a result, UE2 will initiate an RRC proce- 
dure to setup a Dedicated Channel (DCH), i.e. UE2 sends a capacity request (e.g. an 
RRC MEASUREMENT REPORT message) to RNC, which activates DCH for the 
PoC session. Now UE2 is able to send the content of the RLC buffer, i.e. the signal- 
ing message and the dummy data, over DCH to RNS 5, and further to the PoC Server. 
Upon receiving the SIP REFER message, and if the turn to speak (a speech item) is 
granted to UE2, the RNC returns a RTCP Floor Granted message. Upon receiving the 
RTCP Floor Granted message, UE2 will give a Start-to-speak indication (such as a 
beep) to the user, and the user starts to speak. The Voice activity detector VAD will 
detect the speech and start to generate a speech data stream to the RLC buffer. This 
data can be sent immediately since DCH is already set up. However, the start-to- 
speak time (time from pressing the pressel to the start-to-speak indication) is pro- 
longed in comparison with the present case, since DCH is setup in between. 
[0070] In an alternative embodiment of the invention, UE first waits (after the step 83 
in Figure 8) that the signaling message (SIP or RTCP) is fully transmitted over the 
radio before sending the dummy data that would trigger DCH set-up. Now the 
amount of dummy data must alone exceed the triggering threshold. In this approach, 
the sending of the actual start-to-speak message (such as the SIP TRANSFER) and the 
response (such as the RTCP Floor Granted), and thereby the start-to-speak indication, 
are not delayed due to the DCH setup. On the other hand, the DCH setup will still be 
initiated before the user starts to speak. Thus, this approach allows the start-to-speak 
time to remain below 1 second whereas the conversation delay would be decreased in 
comparison with the case where the dummy data is not sent. 
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[0071] In still another embodiment, the sending UE2 does not send any dummy data. 
In such a case, the reduction of the delay will be achieved by the operation of the PoC 
server towards the receiving side, as will be explained below. 

[0072] Upon receiving the initial start-to- speak message (such as the SIP TRANS- 
FER) from and having sent the response (such as the RTCP Floor Granted) to UE2 
(steps 91 and 92 in Figure 8), the PoC server will send an appropriate signaling mes- 
sage (such as the RTCP Floor Taken) to UE3 (step 93). In an embodiment of the in- 
vention, the PoC server also sends dummy data with or immediately after the actual 
signaling message (step 94). The amount of data is such that it alone or together with 
the signaling message exceeds the DCH setup threshold in the serving RNS6 of the 
receiving UE3. As*a consequence, a downlink DCH is setup for UE3 and the signal- 
ing message and the dummy data is sent to UE3 over the established DCH. Since 
DCH is now ready, the subsequent RTP voice stream from UE2 can be sent to UE3 
without the DCH setup delay. Thus, the conversation delay will decrease signifi- 
cantly, typically over 1 second (the DCH setup delay of the receiving user). 
[0073] The inventive operation of the PoC server for the receiving side may be ap- 
plied alone or in combination with any of the above operations of the sending UE. It 
should be noted that although the sending UE would not send any dummy data to trig- 
ger the DCH setup, the server would still decrease speech round trip time delay by 
sending to the receiving UE a dummy message immediately after sending the RTCP 
FLOOR TAKEN message. This server-only solution may in fact be advantageous 
because it would allow to keep the start-to-speak time under 1 second (DCH estab- 
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lishment delay not counted) whereas the Speech round trip time would decrease 
significantly. 

[0074] Figure 10 shows a signaling flow diagram illustrating an example of another 
session event to which the principles of the present can be applied. The present 
speaker, for example the user of UE2, stops speaking. This is indicated by the release 
of the PTT pressel, for instance. UE2 signals the "stop of talk" event to the PoC 
server. This signaling may include a RTCP Floor Release, for example. In response 
to receiving the "stop of talk" signaling, the PoC server indicates the event to the re- 
ceiving UE3 by means of an appropriate signaling. This signaling may include a 
RTCP Floor Idle message. UE3 indicates the event (e.g. Floor Idle) to the user by an 
appropriate indication, such as a beep. After a delay caused by the human reaction, 
the user presses the PTT pressel. This may cause a similar procedure as described in 
connection with Figure 7. The PoC application 301 in the controller 305 detects that 
the pressel PTT is pressed and generates an appropriate message (such as a RTCP 
Floor Request ) and transfers it to the RLC transmit buffer in UE3. Further, in accor- 
dance with an embodiment of the invention, the PoC application (or e.g. the speech 
codec) also generates dummy data which is also transferred to the RLC buffer in UE3. 
The amount of dummy data is such that the total data level in the RLC buffer will ex- 
ceed the DCH threshold (e.g. 200 bytes). As a result, UE2 will initiate a RRC proce- 
dure to setup a Dedicated Channel (DCH), and RNC in RNS6 activates DCH for the 
PoC session. Now UE3 is able to send the content of the RLC buffer, i.e. the signal- 
ing message and the dummy data, over DCH to RNS 6, and further to the PoC Server. 
Upon receiving the message, and if the turn to speak (a speech item) is granted to 
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UE3, the PoC server returns an appropriate response, such as a RTCP Floor Granted 
message. Upon receiving the RTCP Floor Granted message, UE3 will give a Start-to- 
speak indication (such as a beep) to the user, and the user starts to speak after a human 
reaction time. The Voice activity detector VAD will detect the speech and start to 
generate a speech data stream to the RLC buffer. Again, the voice data can be sent 
immediately since DCH is already set up. 

[0075] Alternatively, as in one of the embodiments described above, UE3 may send 
the actual message, e.g. RTCP Floor Granted message, first and the dummy data later. 
Still further, UE3 may send only the actual message, for example RTCP Floor 
Granted message. 

[0076] Upon receiving the initial message (such as the RTCP Floor Request) from 
and having sent the response (such as the RTCP Floor Granted) to UE3, the PoC 
server will send an appropriate signaling message (such as the RTCP Floor Taken) to 
UE2. In an embodiment of the invention, the PoC server also sends dummy data with 
or immediately after the actual signaling message. The amount of data is such that it 
alone or together with the signaling message exceeds the DCH setup threshold in the 
serving RNS5 of UE2. As a consequence, a downlink DCH is setup for UE2 and the 
signaling message and the dummy data are sent to UE2 over the established DCH. 
Since DCH is now ready, the subsequent RTP voice stream from UE3 can be sent to 
UE2 without the DCH setup delay. 

[0077] In all embodiments relating to the second aspect of the invention, the PoC 
server may selectively send dummy data only to the UEs which are located in appro- 
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priate access networks (such as WCDMA), as discussed above relating to the first as- 
pect of the invention. 

[0078] In all embodiments of the invention, the serving access networks of the send- 
ing UE and the receiving UE(s) may be the same one or different ones. 
[0079] It should be appreciated that all the above operation beyond sending the 
dummy data for triggering the DCH setup or resetting inactivity timer may basically 
be implemented in accordance with the 3 GPP specifications and existing PoC func- 
tionality. 

[0080] Various embodiments of the invention have been described, but it will be ap- 
preciated by persons skilled in the art that these embodiments are merely illustrative 
and that many other embodiments are possible. The intended scope of the invention is 
set forth in the following claims, rather than the preceding description, and all varia- 
tions that fall within the scope and spirit of the claims are intended to be embraced 
therein. 



